Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/1007

Internet Message Format | 1994-08-27 | 5.1 KB

Date: Fri, 22 Jul 1994 19:47:23 -0400 (EDT)
From: Timothy Miller <[e-mail]>
Subject: Re: GEM apps, in general
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <Pine.3.87.9407221922.E14466-0100000@grad>
Mime-Version: 1.0
Precedence: bulk

Warwick:

]>       3. Everything that can be done with form_do() can be done
]>               in a window.
]
]Really? What about objc_edit() which can't clip to a rectangle list?

Clicking buttons and sliders in background windows is one thing, but
using editing fields is out of the question.  My application framework
library can handle key messages to background windows, but if the
developer wants to use it, he'll have to comment out some of my code.


Flashman:

]Sorry if I am sounding really dumb here. But how do you want the system
]to tell apart when the user wants to a) top a window or b) control one of
]its gadgets?

My library has flags that can be set that make the window any combination
of: diasabled, untoppable, backactive, and others that I have not
implemented yet.  If you want, say, a tool box, you make the window
backactive and untoppable.

If the window IS toppable and backactive, the current implementation will
top the window and select the button at the same time.

However, some have suggested that:  if something is selectable, act upon
it, but don't top.  If something is NOT selectable, then top the window.


]My concern is that you are now changing "previous" behavior. I know there
]are many good arguments about throwing out previous system behavior. But
]I also think you need to pay close attention to the benefits to
]maintaining previous system behavior.

Yes.  Trying to keep consistent with 'old-style' GEM behavior as much as
possible without letting it get too much in the way of progress is quire
desirable.  Many people will not appreciate being confused by a
user-interface that don't know how to use because the software developer
decided to throw 'normal' behavior out of the window.


Forget:

]may not be more desirable, but then again it might be.  I often shove
]the mouse out of the way when I'm typing.  If my output goes to the
]window the mouse is on, there is a pretty good change I'll knock it
]out.  Or perhaps the cat will jump on the computer table while I'm
]typing, or someone will bump into the table, or whatever.  The point is
]that this could be an annoying/dangerous practice.

Definately a dangerous practice.  Keys should only go to the top window.
Period.  Clicking in a background window can be confusing enough.


Hollis:

]> My solution was to temporarily increase its width by two.
]
]If that was the case do:
]
]x--; y--; w++; h++;

Actually, if you're going to do it that way, you STILL have to increase
the height and width by two, but I found that decreasing x and y really
screwed it up.  Increasing just the height and width by two works great.

I was discussing this with Warwick and then I noticed some example
dialogs for Lattice C for a CPX.  There was a vertical slider and it was
like this:

  The track had a width of 18, border ourside
  The slider had a width of 20, border inside

This would work... except it would probably suffer from the same problem
I get when I DO decrease the x and y of the slider.


Evan:

]If the user clicks the mouse on a selectable and completely unobscured,
]visible object, then why not select it instead of topping the window?  Since
]there is a border area on most dialogs, you can use that to top it, and
]and partially obscured object can be used to top the window.  I know some
]of you are worried about not being to top a window - does the new condition
]or forcing the object to be completely visible satisfy your needs?

I really do not like this at all.  With the way GEM has worked in the
past, a user gets used to just clicking anywhere in a background window
to top it.  I don't want to accidentally select a button I didn't want to
select just because I didn't know that unobscured buttons would be selected.

I HATE the was Microsoft Windows passes mouse events to background
windows when you click to top them.  I like GEM much better.




]========================================================================
]Hey, whatever happened to our discussion of color-palette handling?  I
]especially likes my ideas.  :)  Could someone go back to those old
]messages and digest what was discussed?
]========================================================================
]
]What was your idea?

Uh... I forget.  :)

It was something along the lines of:  No program has to register with out
palette handling utility, although it could use facilities for MAKING
palettes.  Since WM_TOP messages are broadcast globally, our utility
would grab the current palette, assign it to the window that was just
untopped (it keeps track of the top window, so we don't need to worry
abouf WM_UNTOPPED messages), and then set up the palette that was
previously found to be active when the new window was last untopped.



If you don't do vector-grabbing, how do you expect programs to take over
things like BIOS console, inprove AES, etc?